-
Notifications
You must be signed in to change notification settings - Fork 5k
[http-client-csharp-mgmt] code refactoring #50205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[http-client-csharp-mgmt] code refactoring #50205
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
A refactoring PR for the HTTP client management generator, focusing on simplifying method signatures and updating return types.
- Introduces new extension methods on InputServiceMethod for handling long-running operations.
- Updates several methods to return IReadOnlyList instead of single statements.
- Refactors BuildOperationMethod and related methods in ResourceClientProvider to remove the isGeneric parameter and streamline try-catch logic.
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
File | Description |
---|---|
Azure.Generator.Management/src/Utilities/InputMethodExtensions.cs | Adds helper extension methods to determine LRO properties and response types. |
Azure.Generator.Management/src/Providers/ResourceCollectionClientProvider.cs | Refactors return types for building method statements and simplifies method call signatures. |
Azure.Generator.Management/src/Providers/ResourceClientProvider.cs | Simplifies operation method building by removing the isGeneric parameter and restructuring internal try-catch and pipeline-processing logic. |
Comments suppressed due to low confidence (1)
eng/packages/http-client-csharp-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceClientProvider.cs:251
- The field '_clientDiagonosticsField' appears to have a typo. Consider renaming it to '_clientDiagnosticsField' for improved clarity and consistency.
UsingDeclare("scope", typeof(DiagnosticScope), _clientDiagonosticsField.Invoke(nameof(ClientDiagnostics.CreateScope), [Literal("${Name}.${signature.Name}")]), out var scopeVariable),
354e449
to
aab13f8
Compare
...ient-csharp-mgmt/generator/Azure.Generator.Management/src/Utilities/InputMethodExtensions.cs
Outdated
Show resolved
Hide resolved
...ient-csharp-mgmt/generator/Azure.Generator.Management/src/Utilities/InputMethodExtensions.cs
Outdated
Show resolved
Hide resolved
...ient-csharp-mgmt/generator/Azure.Generator.Management/src/Utilities/InputMethodExtensions.cs
Outdated
Show resolved
Hide resolved
...ent-csharp-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceClientProvider.cs
Outdated
Show resolved
Hide resolved
...ent-csharp-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceClientProvider.cs
Outdated
Show resolved
Hide resolved
...-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceCollectionClientProvider.cs
Outdated
Show resolved
Hide resolved
4fc9a68
to
d293824
Compare
9702022
to
7e0e865
Compare
var responseBodyCSharpType = method.GetResponseBodyType(); | ||
CSharpType rawReturnType = method.GetOperationMethodRawReturnType(resourceClientCSharpType, resourceDataType); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so from below - this responseBodyCSharpType
is only used to check if it is null.
the GetOperationMethodRawReturnType
did not really use this value, instead, it construct this value again inside the method.
We have quite a few duplicated and confusing logic here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I kind of think that this isAsync
is breaking up our core logic - we are having so many ternary operator just doing:
isAsync ? wrap typeof Task : originalType;
I think we could remove this isAsync
parameter from this method, and wrap it by isAsync later by another method, such as an extension method to CSharpType
WrapAsync(isAsync)
which returns you the original type if isAsync
is false, or wraps the Task type if isAsync
is true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changes have been made following the review comments.
...-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceCollectionClientProvider.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the Azure HTTP client management code to improve consistency and modularity in how operation methods are built and executed. Key changes include the introduction of dedicated method providers for resource operations (including Exists and GetIfExists), correction of field naming issues, and improved internal encapsulation of client diagnostics and REST client access.
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
File | Description |
---|---|
InputServiceMethodExtensions.cs | Adds extension methods for identifying long-running operations and extracting response types. |
CSharpTypeExtensions.cs | Provides helper methods to wrap CSharpType instances for asynchronous and long-running response handling. |
ResourceOperationMethodProvider.cs | Consolidates logic for building operation methods and handling diagnostics, pipelines, and long-running operations. |
ResourceCollectionClientProvider.cs | Refactors field naming and delegates operation method construction to specialized providers. |
ResourceClientProvider.cs | Refactors operation method creation by delegating to ResourceOperationMethodProvider and updates internal API exposures. |
OperationSourceProvider.cs | Removes unnecessary using directives, cleaning up dependencies. |
GetIfExistsOperationMethodProvider.cs | Introduces a specialized provider to handle GetIfExists operations with tailored return statement logic. |
ExistsOperationMethodProvider.cs | Adds a dedicated provider for Exists operations that converts responses into boolean results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the HTTP management client generator by centralizing operation method creation, introducing reusable extensions, and cleaning up naming inconsistencies.
- Added
InputServiceMethodExtensions
andCSharpTypeExtensions
to encapsulate LRO checks and return‐type wrapping. - Extracted operation‐method generation into
ResourceOperationMethodProvider
and specialized providers forGetIfExists
/Exists
. - Renamed diagnostic fields for consistency and removed duplicated logic in client/provider classes.
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
eng/.../Utilities/InputServiceMethodExtensions.cs | New extensions to detect long‐running operations and derive response body/return types |
eng/.../Utilities/CSharpTypeExtensions.cs | New extensions to wrap CSharpType in Task<> , Response<> , or ArmOperation<> |
eng/.../Providers/ResourceOperationMethodProvider.cs | Centralized method provider handling diagnostics, request/build pipeline, LRO, and returns |
eng/.../Providers/ResourceCollectionClientProvider.cs | Fixed typo in diagnostics field name and adjusted visibility of ResourceClientCSharpType |
eng/.../Providers/ResourceClientProvider.cs | Renamed diagnostics field, delegated operation‐method logic to new provider, exposed internals |
eng/.../Providers/OperationSourceProvider.cs | Removed unused using |
eng/.../Providers/GetIfExistsOperationMethodProvider.cs | Added specialized provider for GetIfExists return handling |
eng/.../Providers/ExistsOperationMethodProvider.cs | Added specialized provider for Exists return handling |
...p-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
...p-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
...p-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
...p-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
...harp-mgmt/generator/Azure.Generator.Management/src/Utilities/InputServiceMethodExtensions.cs
Show resolved
Hide resolved
...harp-mgmt/generator/Azure.Generator.Management/src/Utilities/InputServiceMethodExtensions.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the HTTP client management generator code to improve maintainability and consistency across various provider and extension classes. Key changes include the addition of helper extension methods for CSharp types and input service methods, as well as significant restructuring of operation method providers for update, exists, get-if-exists, and get-all operations.
Reviewed Changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
Utilities/InputServiceMethodExtensions.cs | Added extension methods for determining operation characteristics and return types. |
Utilities/CSharpTypeExtensions.cs | Provided helper methods to wrap and unwrap CSharpType instances for async/long-running operations. |
Providers/UpdateOperationMethodProvider.cs | Introduced a dedicated provider for update operations. |
Providers/ResourceOperationMethodProvider.cs | Refactored the base logic for operation methods, including diagnostic scoping and request processing. |
Providers/ResourceCollectionClientProvider.cs | Updated field names and adjusted contextual parameter handling for collection clients. |
Providers/ResourceClientProvider.cs | Renamed diagnostic field and streamlined operation method creation for resource clients. |
Providers/OperationSourceProvider.cs | Removed unused using directive. |
Providers/GetIfExistsOperationMethodProvider.cs | Created a provider for get-if-exists operations with improved signature handling. |
Providers/GetAllResourceOperationMethodProvider.cs | Added a provider for get-all operations with a placeholder for paging implementation. |
Providers/ExistsOperationMethodProvider.cs | Developed a dedicated provider for checking resource existence. |
.../generator/Azure.Generator.Management/src/Providers/GetAllResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
...p-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
...p-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
.../generator/Azure.Generator.Management/src/Providers/GetAllResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
...p-mgmt/generator/Azure.Generator.Management/src/Providers/ResourceOperationMethodProvider.cs
Outdated
Show resolved
Hide resolved
|
||
public static CSharpType UnWrapAsync(this CSharpType type) | ||
{ | ||
if (type.IsGenericType && type.Name == "Task") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for types, comparing with names would always be problematic.
We could do this instead:
type.IsFramework && type.FrameworkType.GetGenericTypeDefinition() == typeof(Task<>)
to 100% sure identify the Task type, instead of catching some model with the name of Task
for example
if (type.Arguments.Count != 1) | ||
{ | ||
throw new InvalidOperationException($"Task type must have exactly one type argument, but found {type.Arguments.Count}."); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if we do the above changes, we could be confident and remove this throw.
Copilot Generated Pull Request Description is accurate.